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Abstract 

With the discovery of new exploit techniques, novel 
protection mechanisms are needed as well. Miti- 
gations like DEP (Data Execution Prevention) or 
ASLR (Address Space Layout Randomization) cre- 
ated a significantly more difficult environment for 
exploitation. Attackers, however, have recently re- 
searched new exploitation methods which are ca- 
pable of bypassing the operating system's memory 
mitigations. One of the newest and most popu- 
lar exploitation techniques to bypass both of the 
aforementioned security protections is JIT memory 
spraying, introduced by Dion Blazakis [3]. 

In this article we will present a short overview of 
the JIT spraying technique and also novel mitiga- 
tion methods against this innovative class of at- 
tacks. An anti-JIT spraying library was created as 
part of our shellcode execution prevention system. 



tackers improved upon the classic return-into-libc 
technique and started using Return-Oriented Pro- 
gramming (ROP) [4, 7] to bypass DEP. However, 
techniques like ROP still rely on the attacker un- 
derstanding memory layout characteristics, leading 
Microsoft to implement ASLR as countermeasure. 
ASLR renders the layout of an application's ad- 
dress space less predictable because it relocates the 
base addresses of the executable modules and other 
memory mappings. The JIT spraying technique [3] 
was introduced to bypass ASLR and DEP simulta- 
neously. In this article we present our novel mecha- 
nisms which are created specifically to prevent the 
JIT spraying technique from successful execution. 
This research targeted Microsoft Windows operat- 
ing systems with the x86-32 CPU architecture. The 
mitigations specifically focus on the ActionScript 
JIT compiler, which is currently being heavily used 
for this type of attack. 



1 Introduction 

In order to increase the security level of the op- 
crating system, Microsoft has implemented several 
mitigation mechanisms including DEP and ASLR. 
Data Execution Prevention (DEP) is a security fea- 
ture that prohibits the application from executing 
code from a non-executable memory area. To ex- 
ploit a vulnerability, an attacker must first find a 
executable memory region and then be able to fill 
it with necessary data (i.e., shellcode instructions). 
Generally, achieving this goal using old exploita- 
tion techniques is made significantly harder with 
the addition of the DEP mitigation. As a result, at- 



2 JIT Spraying 

There are two general reasons why JIT spraying 
is a very useful exploitation method. Firstly, the 
code generated by the JIT compiler is stored in 
memory marked as executable. This should be ob- 
vious because otherwise JIT compiler would be un- 
able to work correctly on systems shipped with the 
DEP feature. Evidently, if the attacker's code is 
generated by JIT engine it will also reside in the 
executable area. In other words, DEP is not in- 
volved in the protection of code emitted by the JIT 
compiler. This is a very useful method since the 
memory was not marked as executable in prior ap- 
proaches like normal heap spraying. The second 



Requests : 

MEM: 0x057d0090 size=l prot=RWX 
MEM: 0x057d0090 size=c prot=RX 

Generated code : 
0x057d0090 mov edx , [esp+O ch] 
0x057d0094 mov ecx,[edx] 
0x057d0096 call 0fdea9dlah 
0x057d009b ret 

Requests : 

MEM: 0x057d0170 size=l prot=RWX 
MEM: 0x057d0170 size=la prot=RX 

Generated code : 

0x057d0170 mov edx ,[ esp+O ch] 

0x057d0174 push dword [edx+Och] 

0x057d0177 push dword [edx+08h] 

0x057d017a push dword [edx+04h] 

0x057d017d mov ecx,[edx] 

0x057d017f call 0fdea5601h 

0x057d0184 mov eax,04h 

0x057d0189 ret 



reason JIT spraying is powerful is that attacker's 
code location can be predicted correctly [3, 1], so 
at this point ASLR is also no longer a big threat 
for the attacker. In this article we will focus specif- 
ically on detecting JIT code generation required for 
the address discovery methods discussed in the ref- 
erenced citation. The reader is encouraged to have 
a full understanding of the referenced work. 



2.1 JIT Code Generation 

Just-In-Time compilation converts code at run- 
time; typically from bytecode into machine code. 
By doing this, an interpreted program's perfor- 
mance greatly improves. The JIT spraying method 
"forces" the JIT compiler to produce a lot of ex- 
ecutable pages with embedded attacker's code. In 
order to write the code to specific location, the JIT 
compiler must first mark the destination memory 
as writable. Since multiple generated code chunks 
may reside on the same memory page, the JIT com- 
piler marks the entire page as RWX (Readable- 
Writable-Executable). These permissions are nec- 
essary because a different chunk of memory residing 
on the same page may be executed asynchronously 
(for example by a different thread) , resulting in ac- 
cess violation if the requested memory page was 
not executable at that moment. After the code is 
written the compiler marks the destination region 
as RX - readable and executable not writable any- 
more, as shown in Listing 1. 

In order to force the JIT compiler to generate code 
that includes shellcode data, attackers must make 
use of ActionScript operators. Even though Ac- 
tionScript consists of multiple operators like: arith- 
metic, arithmetic compound assignment, bitwise 
etc. only one appears to be used in the currently 
known shcllcodes. Listing 2 presents generated 
code for few different types of operators (expression 
used: a OP b OP c OP d . . .). As a test-case, the 
data values we have used come from one of the very 
few available JIT shellcodcs [1]. 

Listing 2 shows that when it comes to ActionScript 
operators, only XOR appears to produce desirable 
results. For example, with the XOR operator, the 
attacker controls four bytes of every single instruc- 
tion. In other cases the expression arguments do 



Listing 1: Sample listing of changes of memory 
rights requested by JIT compiler. 



not provide precise and predictable control over the 
emitted code blocks. By supplying different argu- 
ments to the expression it is possible to change the 
contents of specified blocks and make them more 
dependable on attacker's arguments, but the XOR 
operator appears to be the best option for shell- 
code usage and that is probably why every known 
JIT shellcode makes use of this operator. Once 
the attacker is able to spray controlled executable 
instructions into the heap, the rest of the exploita- 
tion process goes the standard route. The main 
idea here is to spray the memory with instructions 
that include attacker's payload and then be able 
to transfer the execution there (like for example be 
able to point the instruction pointer (EIP) to the 
address of xor eax, IMM32 operand). 



3 Mitigations 

In order to stop JIT spraying attacks we must be 
able to decide whether the code generated by the 
Just-In-Time engine should be marked as shellcode 
or not. This is not a trivial task, since the shellcode 
detector must not heavily impact the original pro- 
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Operator XDR (") : 

[b8 90 90 90 3c ] mov eax , 03 c909090h 

[35 90 90 90 3c ] xor eax , 03 c909090h 

[35 90 90 90 3c ] xor eax , 03 c909090h 

[35 90 90 90 3c ] xor eax , 03 c909090h 

[35 90 90 90 3c ] xor eax , 03 c909090h 

[35 90 90 90 3c ] xor eax , 03 c909090h 

[35 90 90 90 3c ] xor eax , 03 c909090h 

. . .entire block of xors. . . 

[35 31 d2 58 3c ] xor eax , 03 c58d231h 

[35 80 ca ff 3c ] xor eax , 03 cf f ca80h 



Operator ADD 
[b8 90 90 90 
[f2 Of 2a cO 
[66 Of 28 c8 
[f2 Of 58 c8 
[f2 Of 58 c8 
. . . addsd . . . 
[b8 31 d2 58 
[f2 Of 2a cO 
[f2 Of 58 c8 
[b8 80 ca ff 
[f2 Of 2a cO 
[f2 Of 58 c8 
. . . so on . . . 

Operator MUL 
[b8 90 90 90 
[f2 Of 2a cO 
[66 Of 28 c8 
[f2 Of 59 c8 
[f2 Of 59 c8 
. . . mulsd . . . 
[b8 31 d2 58 
[f2 Of 2a cO 
[f2 Of 59 c8 
[b8 80 ca ff 
[f2 Of 2a cO 
[f2 Of 59 c8 
. . . so on . . . 

Operator DIV 
[b8 90 90 90 
[f2 Of 2a cO 
[66 Of 28 c8 
[f2 Of 5e c8 
[f2 Of 5e c8 

. . . divsd . . . 
[b8 31 d2 58 
[f2 Of 2a cO 
[f2 Of 5e c8 
[b8 80 ca ff 
[f2 Of 2a cO 
[f2 Of 5e c8 
. . . so on . . . 



( + ) : 

3c ] mov eax ,03c909090h 
cvtsi2sd xmmO.eax 
movapd xmml , xmraO 
addsd xmml . xmmO 
addsd xmml , xmmO 

: ] mov eax , 03 c58d231h 
cvtsi2sd xmmO.eax 
addsd xmml.xmmO 
: ] mov eax , 03 cf f ca80h 
cvtsi2sd xmmO.eax 
addsd xmml , xmmO 



*) : 

c ] mov eax ,03c909090h 
cvtsi2sd xmmO.eax 
movapd xmml , xmmO 
mulsd xmml.xmmO 
mulsd xmml , xmmO 

c ] mov eax ,03c58d231h 

cvtsi2sd xmmO.eax 

mulsd xmml , xmmO 
c ] mov eax , 03 cf f ca80h 

cvtsi2sd xmmO.eax 

mulsd xmml , xmmO 



/) : 

c ] mov eax ,03c909090h 
cvtsi2sd xmmO.eax 
movapd xmml , xmmO 
divsd xmml , xmmO 
divsd xmml.xmmO 



c ] mov eax , 03 c58d231h 

cvtsi2sd xmmO.eax 

divsd xmml , xmmO 
c ] mov eax , 03 cf f ca80h 

cvtsi2sd xmmO.eax 

divsd xmml , xmmO 



Listing 2: Code generated by JIT compiler depend- 
ing on the used operator. 



gram performance and it must also be free of false 
positive alerts. At this point there are two general 
approaches to implement in the shcllcodc detector: 

• Signature detection approach (scanning for 
NOP sleds, GetPC code, decoding chunk (de- 
cryption) codes etc.) 

• Heuristic detection approach. 

Signature based detectors are the most simple to 
implement but they also tend to generate a high 
number of false positive alerts. Signature detection 
is often not enough since the attacker may able to 
bypass it by constructing the code in another fash- 
ion [5, 8, 6, 2]. To make the detection process more 
reliable and less static we have decided to use the 
heuristic detection approach. 

As shown in subsection 2.1, before the JIT gen- 
erated code is executed the memory protections 
need to be changed to RX (Read-Executable). 
To achieve this, the JIT engine executes the 
VirtualProtect API function. It appears that 
the JIT generated code always starts at the 
memory address specified as a parameter to the 
VirtualProtect API. This can be a serious ad- 
vantage for detection purposes since at this point 
we know the selected address (API argument) 
is always a valid starting point (entry point) for 
disassembling. A second very useful factor here 
is that the generated code that typically contains 
embedded shcllcodc is generated in a very special 
fashion (see Listing 2): 



mov reg , IMM32 

operation reg , IMM32 

So in case of XOR operator : 

mov eax , IMM32 

xor eax , IMM32 

xor eax , IMM32 



Listing 3: General structure of JIT generated code 
used in JIT spraying. 

Our heuristic detection method is simple but very 
reliable. As shown in Listing 3, every JIT shellcode 
currently available generates instructions that use 
32 bit immediate values as a source operand and 
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the destination operand of such instruction is al- 
ways a register that was previously initialized with 
another 32 bit immediate value. The initialization 
instruction is typically a mov reg , IMM32 or in most 
of the cases a mov eax, IMM32. Our detection algo- 
rithm is described as follows (Algorithm 1): 



Algorithm 1: JIT shellcode detection 

input : region_addr, region size 

output: detection marker 
begin 

foreach found_mov_imm32 do 
num instr i — 

numbadinstr < 

while numinstr < MAX inum do 

instr i — disasm next instr() 

if Hnstr or is terminator (instr) 

then 
L break 
if uses_imm32_operands (instr) 
then 

L num badinstr < num badinstr + 1 

_ num inst r i — num ins tr + 1 

if numbadinstr > MAXi badnU m then 
report_shellcode() 

end 



where: 



Our algorithm calculates the number of bad in- 
structions (instructions that use 32 bit immediate 
operands as source) starting from the initialization 
instruction. This algorithm does not assume any 
specific destination register (so no matter if EAX 
is used or any other x86-32 CPU register). Addi- 
tionally it keeps counting the number of bad in- 
structions even if they are separated by some other 
instruction(s) that does not use 32 bit immediate 
operands (for example by some MMX/SIMD in- 
struction or any other which does not use 32 bit 
immediate operand as long as it is not a block ter- 
minator). It is also worth adding that entire scan- 
ning procedure takes place before attacker will have 
a chance to use the code generated by JIT engine 
since we constantly monitor all of the newly gener- 
ated regions. 

One might argue it would be easier to start the dis- 
assembly from the entry point instead of searching 
for mov reg,IMM32. This is a more expensive ap- 
proach, however, since the speed of that method 
would depend directly on the size of the block gen- 
erated by JIT engine — the longer the block, the 
slower the algorithm. Secondly, disassembling is 
always a very costly process when it comes to per- 
formance. By searching for mov reg,IMM32 and 
starting from that point we do not have to perform 
the entire region's disassembly. 



4 Countermeasures 



• numinstr - represents the number of disassem- 
bled instructions 

• numbadinstr - represents the number of "bad" 
instructions, in other words instructions that 
use 32 bit immediate operands 

• is terminator - represents a function which 

checks if the currently disassembled instruc- 
tion should be marked as terminator (instruc- 
tions like CALL, RET, JMP and so on should be 
considered as terminators 

• uses imm32 operands - represents a func- 
tion which checks if currently processed in- 
struction uses 32 bit immediate operands as 
source 

• MAXibadnum - represents a static number 
which describes the maximum number of "bad" 
instructions in the disassembled block 



As we have described before in subsection 2.1, the 
attacker typically controls the 32 bit immediate 
operands. This gives him an opportunity to use 24 
bits of the controlled value to encode shellcode in- 
structions (since one byte is typically already used 
to perform a semantic NOP (i.e., CMP AL)). In or- 
der to bypass our protection, an attacker could try 
to produce his shellcode by creating multiple lands 
and linking them with short JMP/ JCC jumps (since 
they are only 2 bytes long). By doing this, an at- 
tacker can reduce the number of emitted instruc- 
tions that use 32 bit immediate operands and relo- 
cate them through different memory regions. How- 
ever, we have already created a working mitigation 
for this technique by additional scanning of the im- 
mediate value for JMP/ JCC opcodes. Since those 
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jumps are always short attacker can only jump into 
a location between -128 to +127 bytes from the 
jump instruction. Considering the fact that by us- 
ing this method attacker loses additional space for 
valuable shcllcodc instructions, he must emit a rel- 
atively large number of jump instructions. In our 
method we are not only scanning for JMP/JCC op- 
codes inside of the immediate value, but we also 
check if the destination address of such jump points 
to a valid location that also includes another jump 
instruction and so on. In other words, we are try- 
ing to validate the potential jump chain. This step 
is necessary in order to avoid false-positive alerts. 
By connecting this approach with the previously 
described one in section 3 we have made the JIT 
spraying mitigation a lot harder to bypass. 



5 Testimonials 

Tests showed that anti JIT spraying protection li- 
brary have not generated any false-positive alerts 
when browsing typical sites overloaded with Ac- 
tionScript and flash animations. The library it- 
self has not produced any noticeable changes to the 
original application's performance. All tests were 
performed on Flash version 10c (on Microsoft Win- 
dows Vista and XP operating systems). 



6 Conclusion 

In this article we have presented basic concepts of 
JIT memory spraying. This technique is a good 
countermeasure against protection mechanisms like 
DEP and ASLR and moreover it is getting more 
and more popular. In order to stop JIT spraying 
attacks from successful exploitation we have cre- 
ated mitigation techniques that are solid, reliable 
and fast. We hope the reader found this article 
interesting. 
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